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REMARKS 

INTRODUCTION 

Claims 1-26 were previously and are currently pending and under consideration. 

Claims 1-26 are rejected. 

No claims are amended herein. 

No new matter is being presented, and approval and entry are respectfully requested. 

REQUEST FOR RECONSIDERATION AND NEW OFFICE ACTION 

As discussed below, Applicant respectfully submits that the previously amended claims 
recite features not found in the cited combination. Reconsideration of the rejection is requested. 
If the rejection maintained, a new Final Office Action addressing the remarks below is 
respectfully requested. 



REJECTIONS UNDER 35 USC § 103 

In the Office Action, at pages 3-8, claims 1-26 were rejected under 35 U.S.C. § 103 as 
being unpatentable over Hunkins and Patel. This rejection is traversed and reconsideration is 
requested. 

TIMING OF DISTRIBUTING AND APPLYING UPDATES 

Claim 1 recites automatically updating when the update request is generated (which in 
turn is responsive to an actual database update having occurred). Claim 7 recites appending 
the update request to a queue "when the update request is generated", reading it from the 
queue and "updating the shared subscriber directory server in real-time". See also claims 24- 
26, which recite variations of updating when an update request is generated or responsive to a 
change to subscriber information. Claim 22 recites "updating the shared subscriber directory 
server in real-time based on the update request". 
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Applicant previously explained that in various claims an update in one messaging system 
actuates an update in a central directory used by messaging systems. The Examiner responded 
(Office Action, item (B)), that "Hukins [sic] discloses the use of allowing data to be updated or 
synchronized automatically without user intervention, thereby providing and preserving data 
integrity", citing column 2, lines 48-58. 

Respectfully, Applicant has not taken the position that the claims recite only that "updates 
are synchronized automatically without user intervention". Rather, Applicant's position was that 
according to the relevant claims the updating of data "in a subscriber database" of messaging 
system (claim 1 , e.g.) actuates a corresponding update in the central directory. For example, 
claim 1 recites the directory being updated when the request is generated, and claim 25 recites 
that the update request is sent when it is generated The Examiner correctly noted that updates 
in Hunkins are applied automatically. That is, a user enters an update, request order, and at a 
later prescheduled time the update is applied automatically. Applicant does not disagree that 
Hunkins automatically applies updates. 

However, Applicant has not argued mere automaticity in the relevant claims, rather 
Applicant has pointed out a difference in the timing of directory/target updates in the relevant 
claims. In Hunkins, it is unquestionable that updates are created by a user and then processed 
in a delayed batch fashion. The target synchronization database is not updated "when an 
update request" is made at the source of the update. Rather, an update occurs when a 
"predetermined time arrives (" When the scheduled time is reached , the preferred embodiment 
begins processing each Change Object one by one", column 8, lines 6-9). In Hunkins, the user 
schedules the Project to be executed . See also item 144 in Figure 6 and column 7, line 61 to 
column 8, line 9. Also "the project is then scheduled ... At the appropriate time the project 
[containing update requests] is executed [to update the target databases]" (column 1 1 , lines 9- 
14). This is a clear difference from the relevant claims. 

In other words, Hunkins teaches only that updates are applied to the target automatically, 
rather than a user entering updates a target database. However, in Hunkins the timing is 
scheduled by the user rather than occurring when the original actuating change (or request) is 
made. 
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Applicant respectfully notes that the Examiner did not address the pertinent teachings of 
Hunkins brought to light in Applicant's prior Amendment. The goal of examination is to clearly 
articulate any rejection early in the prosecution process so that the applicant has the opportunity 
to provide evidence of patentability and otherwise reply completely at the earliest opportunity" 
(MPEP § 706). Per MPEP § 707.07(f), "Where the applicant traverses any rejection, the 
examiner should, if he or she repeats the rejection, take note of the applicant's argument and 
answer the substance of it." Applicant respectfully requests an explanation of how Hunkins can 
teach using a source update itself to actuate a target update when Hunkins clearly teaches 
using prescheduled batch processing to time the distribution of an update from an originating 
source to a destination target. 

Put another way, in the relevant claims, a target is updated when a source is updated. 
However, in Hunkins, a user manually changes records in a centralized database 70. This 
generates a "project" which contains the user's changes. At a prescheduled later time, the 
changes are applied to target databases 1 1 , 12, 13, and 14. As stated in Hunkins at column 7, 
line 43, to column 8, line 5: 

"When a change is made to the common database, the 
information ... is placed on the screen for the user ... The user 
modifies one or more fields and then saves or commits those 
changes to the fcommonl database . The preferred embodiment 
generates a Change Object ... The Change Object contains all of 
the information in it that is necessary to change the old record to 
be the new record ... [the system] go[es] into the common 
database — and makes the changes as the user described. 
This happens and the common database is not representative of 
the new data. ... The Change Object is now placed in a batch 
file which is referred to as a Project ... he or she schedules the 
Project to be executed." 

Hunkins updates a common database, generates a batch file (Project containing Change 

Objects), and at the prescheduled time distributes the updates. Hunkins clearly does not update 

a target when the source (common database 100) is updated. 

Withdrawal of the rejection is respectfully requested. 



10 



Serial No. 09/934,582 



NEW REFERENCE: PATEL 

The Examiner acknowledged that Hunkins does not disclose different messaging 
systems. The Examiner has modified the Hunkins reference to apply to different messaging 
systems in Patel. 

Patel discusses a system for providing a central subscriber database accessed by 
different voice messaging systems (VMS's). Figure 3 shows two voice messaging systems; 
VMS #1 , which is item 15 in the figure, and VMS #2, which is item 17 in the figure (note, Figure 3 
erroneously shows item 17 as VMS #1, however, per column 17, line 5, item 17 should show 
"VMS #2"). The VMS's are part of a regionwide messaging system (RMS) and route messages 
between themselves and other elements in the RMS. For the purpose of routing messages, the 
RMS is provided with two regionwide messaging directories, RMD #1 (item 40) and RMD #2 
(item 42). These may be, for example, Lightweight Directory Access Protocol (LDAP) servers. 
Figure 3 also shows a network element 51 , which contains a file 52 used to determine which 
RMD (RMD #1 , or RMD #2) to used to route a given message. In Figure 3, the file 52 indicates 
that messages for area code "404" are routed using RMD #1 , and messages for area code "770" 
are routed using RMD #2. 

Following the circled numbers in Figure 3, a message is routed as follows: 

1 : subscriber 14 sends message (from box 770-925-7666, to 
box 770-925-7666) 

2: VMS #1 passes the area code of the message - "770" - to 
the network element al 

3: network element 51 uses its file 52 to determine that the 
message is routed using RMD #2, which handles the "770" area 
code, this information is sent to the VMS #1 

4: per the feedback from the network element 51 , VMS #1 
sends to RMD #2 the area code and exchange (770-925) of the 
destination box 

5: RMD #2 extracts the routing information from its directory 
45 (note, 770-662 maps to VMS #1), and returns this information 
to VMS #1 

6: VMS #1 routes the message to VMS #1 

7: VMS #2 (item 1 7) receives the message and sends it to 
recipient 38 
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As can be seen in Figure 3, the different routing directories (RMD #1 and RMD #2) each 
have their own mutually-exclusive routing information; directory 44 has area code 404, and 
directory 45 has area code 770. 

A significant aspect of Patel is that different directories contain different routing 
information. This is made possible by the inclusion of network element 51 , which allows a VMS 
to determine which RMD/directory to use when routing a message. 

The reason that Patel takes this approach is to accommodate increasing demand on a 
directory. As discussed at column 9, lines 45-55, directories can be added to increase system- 
wide capacity. Therefore, it is essential that directories each handle their own different routing 
information. As stated further down in column 9, "RMDs 40, 42 do not include a record for each 
subscriber for the messaging system. Rather, the records in each of the RMDs 40, 42 are 
organized pursuant to a scheme that allows for routing information to be obtained regarding the 
subscribers of the messaging system without having to have a record for each subscriber " 
(emphasis added). 

As discussed below with reference to the claims, this basic and unalterable design of 
Patel is, respectfully, both different than the Examiner's characterization and incompatible with 
the design of Hunkins. 

PATEL DOES NOT SYNCHRONIZE DIFFERENT MESSAGE ROUTING DIRECTORIES 

At page 3 of the Office Action, the rejection characterizes Patel as "providing information 
for a routing of messages between or among messaging platforms in a messaging system by 
moving messaging platform to different messaging platform" (last 6 lines of page 3). The 
rejection cites column 2, lines 50-60 of Patel, whose encompassing paragraph states, with 
emphasis added: 

When making a determination as to the organizational scheme for records 
to be included in the directories of the RWM system, the dynamic nature 
of messaging systems must be taken into account. For example, the 
respective assignment of subscribers to messaging platforms may change 
over time in efforts to load balance the overall RWM system. As another 
example, the respective assignment of subscribers to messaging 
platforms may change over time based on movement or other changes 
instituted by the subscriber. To explain, consider a subscriber who moves 
from one geographic area of the RWM system to another. With local 
number portability (LNP), the subscriber may retain his or her directory 
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number, but be served by a different messaging platform of the RWM 
system. In the case of a subscriber's mailbox being moved from a 
messaging platform to a different messaging platform, the record for the 
subscriber in the directory needs to reflect the change in messaging 
platform address so that messages for the subscriber are routed correctly 
and efficiently to the different messaging platform. 

What Patel is describing is the shifting of subscribers to different VMS hosts. For 

example, a user may be shifted to balance load in the overall RWM. If the purpose of shifting a 

user is to balance load, then clearly the user record is not synchronized (kept the same) on 

different messaging platforms, because this would increase or maintain the load on the RWM. 

Furthermore, the cited portion of Patel describes only the information on one directory. The 

cited portion does not describe or suggest synchronization between directories or 

synchronization of subscriber routing information. 

As discussed above in the "PATEL" section, the subscriber routing directories in Patel 
are not synchronized, rather they contain different subscriber routing information. If the 
Examiner's characterization of Patel were correct, directories 44 and 45 in Figure 3 would have 
some common routing information. However, they do not. 

Withdrawal of the rejection is respectfully requested. 

PATEL TEACHES AWAY FROM HUNKINS 

The MPEP, at § 2143.01 , states that "[i]f the proposed modification or combination of the 
prior art would change the principle of operation of the prior art invention being modified, then 
the teachings of the references are not sufficient to render the claims prima facie obvious", and 
a "suggested combination of references" is improper when it "would require a substantial 
reconstruction and redesign of the elements shown in [the primary reference] as well as a 
change in the basic principle under which the [primary reference] construction was designed to 
operate". 

The rejection proposes combining Patel with Hunkins to achieve VMS's that synchronize. 
However, as explained above, Hunkins is explicitly designed not to synchronize or share 
subscriber information. Hunkins teaches database synchronization but has no relation to 
telephone messaging systems and has no central directory for subscriber information. Patel 
teaches a regionwide messaging system with one or more routing directories (RMDs), each 
having subscriber routing information different than the other. That is, each directory stores the 
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information for routing to the subscribers of its own subset of VMS's. Note in Figure 3 that area 
code 404 subscribers are on RMD #1 , and area code 770 subscribers are on RMD #2. 



COMBINATION WOULD SUBSTANTIALY CHANGE REFERENCES 

According to MPE P § 2143.01 , "If the proposed modification or combination of the prior 
art would change the principle of operation of the prior art invention being modified, then the 
teachings of the references are not sufficient to render the claims prima facie obvious", further 
discussing that a combination is improper where it would require a "substantial reconstruction 
and redesign of the elements shown in [the primary reference] as well as a change in the basic 
principle under which the [primary reference] construction was designed to operate." 270 F.2d at 
813, 123USPQ at 352.). 

As discussed above, Hunkins discloses database synchronizing, and Patel discloses 
databases that are explicitly designed to be different (not synchronized). See also item (A) of 
the Office Action, stating that "Applicants should duly note that Hukins [sic] for [sic] 
synchronizing data in multiple, disparate databases, thereby providing greater accuracy and 
preserving data integrity". In other words, the disparate databases are synchronized to have 
essentially identical contents. As also discussed above, the directories in Patel are purposefully 
different, and routing a message is accomplished using a network element having information 
used by a VMS to chose the proper directory for routing a message. The references are 
inherently incompatible; one teaches synchronization, the other is explicitly designed to 
accommodate different directories. A combination of these references would require a 
considerable redesign of either or both references. 

Furthermore, Hunkins is cited as the primary reference and it is suggested that it be 
modified to include telephony messaging systems. That is, the rejection proposes modifying 
Hunkins to include a regionwide messaging system as in Patel. However, modifying a system 
for synchronizing close-related databases on an organization's network to include the entire 
functionality of a telephony messaging system would clearly require a substantial reconstruction 
of Hunkins. 
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COMBINATION DIFFERS FROM CLAIMS 

Although Applicant respectfully but firmly submits that the combination is impossible, 
Applicant also notes that the combination also does not match all of the features of the claims. 
According to claim 1 , for example, one of the messaging systems sends an update request to a 
central directory that is shared by different messaging systems. However, Hunkins only teaches 
databases synchronization. That is, different databases in effect mirror each other. This is 
different than systems forwarding their updates to a central directory where they can be shared 
by other systems. 

Withdrawal of the rejection is further respectfully requested. 

SUGGESTED MOTIVE TO COMBINE REFERENCES LACKS BASIS IN HUNKINS 

The rejection "states that the motive for the combination is that it "would provide Hunkins 
the enhanced capability of allowing for routing information to be obtained regarding the 
subscribers of the messaging systems" (Office Action, page 4, top). However, the rejection 
provides no explanation of why this is necessary or desirable. Hunkins does not even include 
messaging systems or subscribers of messaging systems, so there is no capability to be 
enhanced (note, the claims recite telephony messaging systems). Applicant respectfully 
requests clarification of the suggested motive. 

Withdrawal of the rejection is respectfully requested. 



CONCLUSION 

There being no further outstanding objections or rejections, it is submitted that the 
application is in condition for allowance. An early action to that effect is courteously solicited. 

Finally, if there are any formal matters remaining after this response, the Examiner is 
requested to telephone the undersigned to attend to these matters. 
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If there are any additional fees associated with filing of this Amendment, please charge 
the same to our Deposit Account No. 19-3935. 

Respectfully submitted, 

STAAS & HALSEY LLP 



Jarre's' T. Strom 
Redistration No. 48,702 

1 201 New York Ave, N.W., Suite 700 
Washington, D.C. 20005 
Telephone: (202)434-1500 
Facsimile: (202)434-1501 
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